I've exposed this and annotations_edit() publicly to be used in the language server but It feels weird to expose them from the cli crate. If it should be in another crate what one?

If there's a problem loading the file then it just prints out the error. I know this needs to be updated but I'm not sure what the error message should be. Should it include the loading problem or just say that there was one?

It seems that if there's an error in the type, don't we want to cancel the operation, no?

maybe? These only seem show up when a type doesn't implement an ability it's supposed to. I'm not sure how I'd go about detecting all type errors. I could try looking for

• Error
• FlexVar(None) or FlexAbleVar(None, ...) that show up anywhere except as arguments
• FlexVar or FlexAbleVar that have names that start with '#'

But that still allows things like List.first(8) which has the type Result a [ListWasEmpty]. I'm not sure if that would be counted as an error or not? a doesn't come from anywhere so maybe that means it is?

This stuff is a bit over my head so maybe I'm missing something but I don't see anything in the codebase for this already

The other way to disallow errors is not from the type but if the code itself has any warnings or errors but that seems a bit heavy handed

a doesn't come from anywhere so maybe that means it is?

I think (this is not really my area...) that may be fine, and the constraint is that a needs to be a fresh name (not bound in the outer scope).

Maybe @bhansconnect has more specific advice about how we should be applying types here?

I would short circuit and break out if there are any errors in types, I think it's too easy to generate wrong annotations otherwise. If the easiest method to implement it is to check if the code has any errors, I think that's fine at this moment in time

I've added an early return for generated annotations that contain type errors. It only handles cases that are explicit errors though (Content::Error or generated names with #). So it won't ever generate an incorrect annotation, but it will generate annotations for incorrect code that, when fixed, has a different type. The problem I found with short circuiting on compile errors is that they aren't local to the value being annotated, so it would have to error out on any compile error for the whole program. I think that would make it unusable in practice. Does that all sound good?

I think[cancelling after any compiler error] would make it unusable in practice.

It's still useful if what you've done is fixed all your errors and you now want to annotate everything.

I guess I don't feel super strongly, but my gut tells me that generating annotations for cases we're not absolutely sure there aren't problems with, is going to cause some users a lot of confusion (i.e. what @ayazhafiz is saying).

This is something we can adjust as we go / if we get feedback tho, so I'm not super concerned.